Conversation
code-crusher
commented
Feb 2, 2026
- ui updates + tool updates + model updates
- updates tests
- clean up chat text area
- feat: add beta models gating for axon-code-2-pro
- set temp to 0.2
- fix beta model access
9e86d60 to
21b8f3a
Compare
| // kilocode_change start: Fetch beta models availability on mount and when API config changes | ||
| useEffect(() => { | ||
| if (didHydrateState && apiConfiguration?.kilocodeToken) { | ||
| vscode.postMessage({ type: "fetchBetaModelsRequest" }) | ||
| } | ||
| }, [didHydrateState, apiConfiguration?.kilocodeToken]) | ||
|
|
||
| // Additional effect to refresh beta models when switching between API configurations |
There was a problem hiding this comment.
🟡 Performance
Issue: Redundant useEffect hooks. The new debounced effect (lines 261-275) duplicates the functionality of the existing effect (lines 255-259) regarding kilocodeToken changes. Having both active causes double network requests (one immediate, one delayed) and potential race conditions.
Fix: Remove the old immediate effect and the "Additional" qualifier from the new effect's comment, relying solely on the new debounced implementation.
Impact: Prevents duplicate API calls and race conditions.
| // kilocode_change start: Fetch beta models availability on mount and when API config changes | |
| useEffect(() => { | |
| if (didHydrateState && apiConfiguration?.kilocodeToken) { | |
| vscode.postMessage({ type: "fetchBetaModelsRequest" }) | |
| } | |
| }, [didHydrateState, apiConfiguration?.kilocodeToken]) | |
| // Additional effect to refresh beta models when switching between API configurations | |
| // Effect to refresh beta models when switching between API configurations |
| })) | ||
| } | ||
| const payload = message.payload as { enabled?: boolean; success?: boolean } | ||
| const enabled = payload?.enabled ?? payload?.success ?? false |
There was a problem hiding this comment.
🟠 Security / Logic
Issue: Insecure default behavior. The fallback ?? payload?.success evaluates to true if enabled is missing or null (assuming the request succeeded). Feature flags should strictly default to false (fail closed) when the status is indeterminate to prevent unauthorized access.
Fix: Remove the fallback to payload.success and default to false if enabled is not explicitly provided.
Impact: Ensures the feature remains disabled if the API response is ambiguous.
| const enabled = payload?.enabled ?? payload?.success ?? false | |
| const enabled = payload?.enabled ?? false |